In a service-oriented architecture (SOA) system, which has a process chain of service offerings, each of the service offerings can have its own rules. The SOA system provides a conventional technique to expose pieces of service offerings that might be composable.
Using SOA techniques, a provider can execute a complete process chain for an overall process by combining offerings of different partners that can each supply one or more services to undertake steps of the overall process. For this process, the provider conventionally employs a so-called partner portal that allows the partners to make their respective service offerings known to the provider. Typically, the partner that provides one of the service offerings also provides the self-describing definitions for the service.
The definitions for each of the services are not necessarily confluent, even when the services are in a process chain. Furthermore, each of the offered services might have legal and/or internal restrictions which limit the functioning of the services.
The rapidly expanding number of offered services makes it increasingly difficult to guide service definitions to the needs of the provider.
An SOA governance system is used for activities related to exercising control over services in a SOA. In addition to the service definitions, another of the operational elements of a conventional governance model is an access control infrastructure which is used in order to check authorization, using access control policies and security assertions written in a specialized grammar such as XACML or SecPAL.
As an example of service definitions, consider U.S. Pat. No. 7,801,976, to Hodges et al., which discloses a SOA method to capture service properties in service process profiles, and among other things to interrogate possible services by reviewing service properties captured in the service process profiles. According to Hodges, machine-readable (e.g., XML-based) metadata may be used to capture the self-describing service profiles.
U.S. Pat. No. 7,739,228, to Erickson et al., discloses a method of generating a services repository using a target services roadmap, which receives an identification of an implemented service from the user and maps the implemented service to target services. Erickson uses, among other things, a service description which can be the definition of a reusable business function that endpoints can consume.
These and other known solutions are examples of standard techniques for self-describing services as well as techniques to check these descriptions against certain rules and/or policies.
Nevertheless, the problem remains that the service descriptions are insufficiently flexible and not readily extensible, especially for the purposes of the provider of the process chain which combines offerings of separate partners.